A Philosophy of Software Design, 2nd Edition
- Downloads：2069
- Type：Epub+TxT+PDF+Mobi
- Create Date：2021-08-04 16:16:03
- Update Date：2025-09-23
- Status：finish
- Author：John Ousterhout
- ISBN：173210221X
- Environment：PC/Android/iPhone/iPad/Kindle
- Download
Reviews
Christoph Kappel
，
I really enjoyed reading this book， especially if you've read Clean Code: A Handbook of Agile Software Craftsmanship before。 This one isn't that religious， but certainly similar opinionated。In general most of the ideas felt more reasonable， like the points about shallow and deep modules or when to split classes。 Also I really like how essential code docs are for the author， because I feel the same。 Normally， business code rarely includes comments at all and I usually have to make my own， to avoi I really enjoyed reading this book， especially if you've read Clean Code: A Handbook of Agile Software Craftsmanship before。 This one isn't that religious， but certainly similar opinionated。In general most of the ideas felt more reasonable， like the points about shallow and deep modules or when to split classes。 Also I really like how essential code docs are for the author， because I feel the same。 Normally， business code rarely includes comments at all and I usually have to make my own， to avoid re-learning blocks I've already visited。 。。。more
Avraam Mavridis
，
Even after reading it I am not sure what is the goal of the book， anyway， it has some good parts like the chapter for the comments and about readability， it has some other parts that I dont much agree， but the main problem is that the book is very swallow， the author spends 2-3 pages trying to make a point for a subject but。。。 most of the times are simple not enough。 Also I dont get what was the point of the "Trends" chapter and how Design Patterns are fitting there as a trend Even after reading it I am not sure what is the goal of the book， anyway， it has some good parts like the chapter for the comments and about readability， it has some other parts that I dont much agree， but the main problem is that the book is very swallow， the author spends 2-3 pages trying to make a point for a subject but。。。 most of the times are simple not enough。 Also I dont get what was the point of the "Trends" chapter and how Design Patterns are fitting there as a trend 。。。more
Hugues Le Gendre
，
À la fois philosophique et en même temps très pratique， c’est un bon guide du design de systèmes。 Certains principes sont mêmes adaptables dans la vie courante…
Koh
，
This review has been hidden because it contains spoilers。 To view it， click here。 Summary of Design Principles1。 Complexity is incremental: you have to sweat the small stuff。2。 Working code isn't enough。3。 Make continual small investments to improve system design。4。 Modules should be deep。5。 Interfaces should be designed to make the most common usage as simple as possible6。 It's more important for a module to have a simple interface than a simple implementation 。7。 General-purpose modules are deeper。8。 Separate general-purpose and special-purpose code。9。 Different layers shou Summary of Design Principles1。 Complexity is incremental: you have to sweat the small stuff。2。 Working code isn't enough。3。 Make continual small investments to improve system design。4。 Modules should be deep。5。 Interfaces should be designed to make the most common usage as simple as possible6。 It's more important for a module to have a simple interface than a simple implementation 。7。 General-purpose modules are deeper。8。 Separate general-purpose and special-purpose code。9。 Different layers should have different abstractions。10。 Pull complexity downward。11。 Define errors and special cases） out of existence。12。 Design it twice。13。 Comments should describe things that are not obvious from the code。14。 Software should be designed for ease of reading， not ease of writing。15。 The increments of software development should be abstractions，。Summary of red flags- Shallow Module: the interface for a class or method isn't much simpler than its implementation 。- Information Leakage: a design decision is reflected in multiple modules。- Temporal Decomposition: the code structure is based on the order in which operations are executed， not on information hiding。- Overexposure: api forces callers to be aware of rarely used features in order to use commonly used feature。- Pass-through Method: a method does almost nothing except pass its arguments to another method with a similar signature。- Repetition: a nontrivial piece of code is repeated over and ove。- Special-general Mixture: special-purpose code is not cleanly separated from general purpose code。- Conjoined Methods: two methods have so many dependencies that its hard to understand the implementation of one without understanding the implementation of the othe。- Comment Repeats Code: all of the information in a comment is immediately obvious from the code next to the comment 。- Implementation Documentation Contaminates Interface: an interface comment describes implementation details not neexied by users of the thing being dwumented。- Vague Name: the name of a variable or method is so imprecise that it doesn't convey much useful information 。- Hard to Pick Name: it is difficult to come up with a precise and intuitive name for an entity 。- Hard to Describe: in order to be complete， the documentation for a variable or method must be long。- Nonobvious Code: the behavior or meaning of a piece of code cannot be understood easily。 。 。。。more
Daniela
，
Um dos melhores livros que já li referente a como escrever códigos bom para serem lidos。No final tem um sumário dos princípios。
J Balaji
，
A must read for any Software Engineer。 My advice is to read it with an open mind and form your own guidelines for software design rather than blindly accepting or rejecting the ideas laid out in the book。
Tyler
，
Must read for devs。
Henrik Warne
，
A short， compact book with many good ideas， even though I don't agree with everything in it。 The main idea in the book is that modules should be "deep"， that is the implementation should be substantially bigger than its interface。 That way you reduce the complexity of the system， because you only need to know the interface to use the module。Another great idea is to "define errors out of existence"。 There are several good examples of where you can write your function in such a way that it need no A short， compact book with many good ideas， even though I don't agree with everything in it。 The main idea in the book is that modules should be "deep"， that is the implementation should be substantially bigger than its interface。 That way you reduce the complexity of the system， because you only need to know the interface to use the module。Another great idea is to "define errors out of existence"。 There are several good examples of where you can write your function in such a way that it need not throw exceptions。 This too reduces the complexity of the system （by the way， the book starts with a great chapter defining complexity）。A big portion of the book is dedicated to comments。 The author wants more comments in code than I think is called for。 Towards the end， there is also a chapter on optimization that I liked。 It contains a good example of optimizing buffer allocation in a system called RAMCloud。 However， there are also a few weaker chapters towards the end。Overall though， I think this is a good addition to your library of programming books。There is a longer review of this book on my blog: https://henrikwarne。com/2021/07/12/bo。。。 。。。more
Thibault Martin-Lagardette
，
John's book is an incredible piece that all developers， junior or senior， should try to read。 John has obviously been bit by many design decisions over the years， and was able to come up with different suggestions and advice that help write good quality software that has as few bugs as possible and that remains maintainable over time。For years now I had been struggling to explain in code reviews or design sessions the reasons why I gave certain recommendations。 While I have learned over time to John's book is an incredible piece that all developers， junior or senior， should try to read。 John has obviously been bit by many design decisions over the years， and was able to come up with different suggestions and advice that help write good quality software that has as few bugs as possible and that remains maintainable over time。For years now I had been struggling to explain in code reviews or design sessions the reasons why I gave certain recommendations。 While I have learned over time to explain my decisions and design suggestions through what they help prevent/avoid or how they enable other developers， too many times still， all I had was an inkling， a feeling， an intuition。 Instead， John's book clearly lay out all those things I have learned the hard way， and explains them with ease and simple examples。This is the very first programming book where I agree with almost everything that is written。 I am looking forward to share this book with colleagues。 。。。more
Mario
，
it's phine （haha） it's phine （haha） 。。。more
Julien Sobczak
，
Much more insightful than the classic Clean Code。If Clean Code is about the obvious， A Philosophy of Software Design is about the subtle。 This short book goes deeper and is more insightful than its predecessor。 Writing clean code is great， but having a clean design is greater， and I would like more developers to read this book instead of the popular one written by Bob Martin。For many years， the author questioned if software design can be taught， and if design skill is what separates great progra Much more insightful than the classic Clean Code。If Clean Code is about the obvious， A Philosophy of Software Design is about the subtle。 This short book goes deeper and is more insightful than its predecessor。 Writing clean code is great， but having a clean design is greater， and I would like more developers to read this book instead of the popular one written by Bob Martin。For many years， the author questioned if software design can be taught， and if design skill is what separates great programmers from average ones。 The result was a new course at Stanford， and after three iterations， this book emerged。 A Philosophy of Software Design is clearly not the definitive book on the subject。 Only a few real-world projects， mostly written in OO languages， are used to illustrate the principles， and there is so much more to cover about good software design。 But as an introduction on the subject， the book is excellent， especially for students。I found many references to this book by researching about the perils of clean code。 A function is often more maintainable when the number of lines of code is small but sometimes， a longer function is preferable。 A class is often more maintainable when it has a single responsibility but sometimes， making the common case as simple as possible is preferable。 The book is filled with many examples like these。 The discussions about some principles like "Design it twice" or "General-purpose modules are deeper" are invaluable。 If you want to write clean code， you have to think， and this book will help you ask a lot of questions。If you read the reviews of any book about code design， you will have a lot of divergent opinions。 This book is no exception。 The best option is thus to read not just one book， but a lot。 Make sure to include this one in your reading list。 。。。more
Vasil Kolev
，
As usual with this kind of books， some of the advice needs to be taken with a grain of salt （others also have pointed the large emphasis on comments， which to me even seem to be the wrong word， and what the author means is code documentation， which should be a separate topic）。 But even with that taken into account， the advice in the book is solid and down-to-earth， and addresses a lot of the problems I've seen with production code。 This is a great read for pretty much any level of programmer， as As usual with this kind of books， some of the advice needs to be taken with a grain of salt （others also have pointed the large emphasis on comments， which to me even seem to be the wrong word， and what the author means is code documentation， which should be a separate topic）。 But even with that taken into account， the advice in the book is solid and down-to-earth， and addresses a lot of the problems I've seen with production code。 This is a great read for pretty much any level of programmer， as it not only has good advice but also some great examples and stories。（and I thought that there's no way I'd like anything from the author of tcl， but here we are :） ） 。。。more
Christian
，
some good points， but nothing really new or insightful。some points I disagree （about TDD）。some points I really would have liked included （FP， DevOps）。It's unfortunately very OOP centric， and very low code level。 some good points， but nothing really new or insightful。some points I disagree （about TDD）。some points I really would have liked included （FP， DevOps）。It's unfortunately very OOP centric， and very low code level。 。。。more
Marcin Czarkowski
，
Perełka wśród książek o tym jak pisać czysty kod i zarządzać złożonością oprogramowania。 Czym wyróżnia się na tle swojego najpopularniejszego konkurenta？ Przystępnością， zwięzłością i doborem przykładów。 Niektóre opinie autora stoją w całkowitej opozycji do praktyk rekomendowanych przez Uncle Boba: krytyka krótkich metod， konieczność pisania dużej ilości komentarzy。 Mimo że nie przekonały mnie do zmiany nawyków， argumenty Ousterhouta w tych kwestiach były dobrze przemyślane i poszerzyły moją per Perełka wśród książek o tym jak pisać czysty kod i zarządzać złożonością oprogramowania。 Czym wyróżnia się na tle swojego najpopularniejszego konkurenta？ Przystępnością， zwięzłością i doborem przykładów。 Niektóre opinie autora stoją w całkowitej opozycji do praktyk rekomendowanych przez Uncle Boba: krytyka krótkich metod， konieczność pisania dużej ilości komentarzy。 Mimo że nie przekonały mnie do zmiany nawyków， argumenty Ousterhouta w tych kwestiach były dobrze przemyślane i poszerzyły moją perspektywę。 。。。more
Natalie
，
The book I wish I had read when first began my career in software engineering。 Ousterhout makes a compelling， logical case for addressing complexity in software with simple designs augmented with clearly communicated documentation， rather than prioritizing getting something working as fast as possible。 A philosophy that may seem like common sense， but an important one that should be regularly reviewed by any dev， no matter what stage in their career。Linus Torvalds， on the beauty of programming: The book I wish I had read when first began my career in software engineering。 Ousterhout makes a compelling， logical case for addressing complexity in software with simple designs augmented with clearly communicated documentation， rather than prioritizing getting something working as fast as possible。 A philosophy that may seem like common sense， but an important one that should be regularly reviewed by any dev， no matter what stage in their career。Linus Torvalds， on the beauty of programming: "It’s still hard to explain what can be so fascinating about beating your head against the wall for three days， not knowing how to solve something the better way， the beautiful way。 But once you find that way， it’s the greatest feeling in the world。" 。。。more
Afrizal
，
The author successfully identified the main problem of software design that need to be tackled。 Something I haven't got from other similiar books。 I agree with most part with few concerns about comment and global variable usage。 So recommended as food of thought for all engineers。 The author successfully identified the main problem of software design that need to be tackled。 Something I haven't got from other similiar books。 I agree with most part with few concerns about comment and global variable usage。 So recommended as food of thought for all engineers。 。。。more
Claudio Rodrigues
，
That's a good book。 If you are a seasoned software designer you probably have already seen many of the issues discussed in the book and tried the solutions as well。 For those in the early stages of their careers， it's a great reference。I prefer the distinction that Don Norman does in his books between Complexity and Complicated。 In this book， though， the author uses the term Complexity very loosely， almost always meaning Complicated。 That's a good book。 If you are a seasoned software designer you probably have already seen many of the issues discussed in the book and tried the solutions as well。 For those in the early stages of their careers， it's a great reference。I prefer the distinction that Don Norman does in his books between Complexity and Complicated。 In this book， though， the author uses the term Complexity very loosely， almost always meaning Complicated。 。。。more
kevin
，
I like short software books like that with a clear theme。 It centers around how to deal with complexity through the right abstraction。 There quite a bit around comments and documentation which makes a lot of sense and are new to me。 There is a strong argument for having deep methods that do a lot rather than simplistic methods that are clean code style。 The examples are relevant and clear。 My only pity is I do not engage in much serious software engineering these days to see how it works when pr I like short software books like that with a clear theme。 It centers around how to deal with complexity through the right abstraction。 There quite a bit around comments and documentation which makes a lot of sense and are new to me。 There is a strong argument for having deep methods that do a lot rather than simplistic methods that are clean code style。 The examples are relevant and clear。 My only pity is I do not engage in much serious software engineering these days to see how it works when practiced。 Still it gives me idea on what to do in the programming-at-large， high-level architecture， and how to refactor abstraction rather than feature。 。。。more
André Pitombeira
，
This book is all about how to deal with software complexity by applying some simple design techniques。 I’m familiar with most of the approaches presented in the book， but I found interesting the trade-offs the author made with well established techniques。 For example， when the author talks about TDD he brings up that if you focus too much in the features you’re building。 Then， your design might not receive enough attention and you will end up with tactical programming， i。e focusing only on devel This book is all about how to deal with software complexity by applying some simple design techniques。 I’m familiar with most of the approaches presented in the book， but I found interesting the trade-offs the author made with well established techniques。 For example， when the author talks about TDD he brings up that if you focus too much in the features you’re building。 Then， your design might not receive enough attention and you will end up with tactical programming， i。e focusing only on development and forgetting about maintenance。Besides that， the book explores some techniques to design deep modules， write good comments， deal with performance， and so on。 It is definitely a must read for developers。 。。。more
Daniel Dao
，
It was a pretty good book。 I really liked the first half and the second half kind of fell flat。 I wish there was also more code examples。 In my opinion this is a solid book for a person a few years into their careers。 The lack of code examples makes it hard to actually imagine use cases sometimes， but with more code exposure， then it's easier to imagine。 It was a pretty good book。 I really liked the first half and the second half kind of fell flat。 I wish there was also more code examples。 In my opinion this is a solid book for a person a few years into their careers。 The lack of code examples makes it hard to actually imagine use cases sometimes， but with more code exposure， then it's easier to imagine。 。。。more
Tyler Deren
，
A must read for any software developer that wishes to level up！
Joshua Horvath
，
Good ideas and information， a little dryly written though。
William Yip
，
The author was a bit repetitive as he stated some of his advice multiple times。 Some of the advice was either common-sense or impractical such as give variables specific names and write numerous comments。 That said， he had plenty of good advice centered on the necessary objective of reducing complexity: think of each written line of code as an investment， create deep classes/modules and simple interfaces， think twice about a potential line of code， and write comments that describe the why instea The author was a bit repetitive as he stated some of his advice multiple times。 Some of the advice was either common-sense or impractical such as give variables specific names and write numerous comments。 That said， he had plenty of good advice centered on the necessary objective of reducing complexity: think of each written line of code as an investment， create deep classes/modules and simple interfaces， think twice about a potential line of code， and write comments that describe the why instead of the how。 I also liked the chapter on how to optimize and speed up critical code。 。。。more
Hunter Herman
，
This book is greatI don’t think some of the more popular comments here actually read the book （most likely they skimmed it）。 Many of these reviews are projecting practices （DRY， self documenting code， single responsibility principle） that the author explicitly disagrees with。 Many of the poor reviews seem to come from people who either don’t understand the book， or who are set on disagreeing with it。 I think this book has a lot of unconventional wisdom， and will help you to grow as a programmer This book is greatI don’t think some of the more popular comments here actually read the book （most likely they skimmed it）。 Many of these reviews are projecting practices （DRY， self documenting code， single responsibility principle） that the author explicitly disagrees with。 Many of the poor reviews seem to come from people who either don’t understand the book， or who are set on disagreeing with it。 I think this book has a lot of unconventional wisdom， and will help you to grow as a programmer with independent views that are not as tightly coupled to What Uncle Bob Says。 。。。more
Alecsphys
，
A nice and easy reading where you can find many concepts developers master during years of coding and code reviewing。 The main idea described in the book is about complexity and how to reduce it。 Some topics are controversial but worth to be thought about。 A book I suggest for newbies starting their career in software engineering， but also for more experienced people who can use it for having some guidelines in code reviewing。
Redowan Nafi
，
A book that has the word philosophy in its moniker but deals with a paradigm that is fundamentally driven by pragmatism， is almost always destined to suffer from obfuscation and extraneous pedantry—and this book is no different。 However， the author did warn the readers of the abstract nature of the text in the preface。The book leans toward object-oriented software design， and almost all the examples are given either in Java or C++。 The first half of the book talks about tactical versus strategic A book that has the word philosophy in its moniker but deals with a paradigm that is fundamentally driven by pragmatism， is almost always destined to suffer from obfuscation and extraneous pedantry—and this book is no different。 However， the author did warn the readers of the abstract nature of the text in the preface。The book leans toward object-oriented software design， and almost all the examples are given either in Java or C++。 The first half of the book talks about tactical versus strategic programming， designing lean interfaces like the Unix I/O， hiding information behind walls of deep abstractions， why deep modules are preferable to shallow ones， and how to write maintainable software。The second half of the book became gratuitously garrulous on code comments。 Also， it tries to touch on everything from event-driven programming， test-driven development to agile agendas。 To me， the second half felt rushed as it tried to touch on everything and ended up teleporting itself into the land of mediocrity。 Overall， I'd recommend this book to anyone who enjoys pondering on the prospects and style of enterprise programming and believes that imperative style object-oriented programming can be a path to reach the eternal nirvana of flawless software design。 。。。more
Julian Schrittwieser
，
Good advice on how to approach software design with real-world examples
Hlynur Freyr
，
Enjoyed the first half of the book when discussing some nice design patterns and nonobvious red flags for complexity。 I liked several concepts used in the book such as deep vs。 shallow modules and strategic vs。 tactical programming。 The second half was less enjoyable as it discussed comments way too much compared to other issues。 A lot of the examples in the second half to try to convince you of the patterns were not good enough as they compared an ideal case to the worst possible case that ever Enjoyed the first half of the book when discussing some nice design patterns and nonobvious red flags for complexity。 I liked several concepts used in the book such as deep vs。 shallow modules and strategic vs。 tactical programming。 The second half was less enjoyable as it discussed comments way too much compared to other issues。 A lot of the examples in the second half to try to convince you of the patterns were not good enough as they compared an ideal case to the worst possible case that every single linter would catch and has never been an issue in my career。 Overall it was quite enjoyable and gets directly to the point as it is rather short。 。。。more
Henri Kotka
，
This book was excellent， would recommend to anyone developing software。 Easy to read and comprehend！
Justin Stanley
，